%sin pauses
\documentclass[handout]{beamer}
%con pauses
%\documentclass{beamer}

\usepackage[utf8]{inputenc}
\usetheme{Warsaw}
\usepackage[spanish]{babel}
\usepackage[T1]{fontenc}

%Para poder hacer footnotes
% \setbeamertemplate{sidebar right}{}
% \setbeamertemplate{footline}{\hfill\usebeamertemplate***{navigation symbols}}

\title{Plan 9 From Bell Labs}
\author{Dardo Marasca, Adrián Sedoski Croce, Benito Vitale}

\begin{document}

	%CARATULA
	\begin{frame}
		\titlepage
	\end{frame}

	%CONTENIDO
	\begin{frame}
    	\frametitle{Contenido}	
		\begin{itemize}
			\item<1-> Introduccion
			\item<2-> Diseño
			\item<3-> Espacio de nombres
			\item<4-> El protocolo 9P
			\item<5-> Herramientas de programación
			\item<6-> Sistema gráfico de Ventanas de Plan 9.
			\item<7-> Sistema de almacenamiento
			\item<8-> Red y comunicaciones      
			\item<9-> Seguridad
			\item<10-> Performance
			\item<11-> Impacto y actualidad
		\end{itemize}	
	\end{frame}

	\begin{frame}
		\frametitle{Introducción}
		\framesubtitle{¿Qué es Plan 9?}	
     	\begin{itemize}
			\item<1-> Es un sistema operativo multiusuario de propósito general.
			\item<2-> Tiene un enfoque fuertemente distribuido.
			\item<3-> Se basa en conceptos de UNIX.
			\item<4-> Muchos de estos conceptos que propone fueron incorporados de vuelta en sistemas basados en UNIX (Particularmente en Linux). 
			\item<5-> En esta presentación vamos a hablar todo el tiempo de UNIX clásico.
		\end{itemize}	
	\end{frame}
  
	\begin{frame}
		\frametitle{Introducción}
		\framesubtitle{Historia}	
		\begin{itemize}
			\item<1-> A mediados de los 80, la tendencia en computación iba alejándose de los grandes sistemas centralizados de tiempo compartido y acercándose hacia redes de maquinas personales.
			\item<2-> La mejor fué su uso de un sistema de ficheros para coordinar el nombre y el acceso a los recursos.
			\item<3-> Cuando los microordenadores se hicieron más rápidos, incluso esta pérdida de potencia se recuperó y este es el estilo de trabajo que permanece todavía hoy.
		\end{itemize}	
	\end{frame}
  
	\begin{frame}
		\frametitle{Introducción}
		\framesubtitle{Historia}	
		\begin{itemize}
			\item<1-> En la loca carrera hacia los ordenadores personales, algunas de sus carencias fueron pasadas por alto.
			\item<2-> El sistema operativo que ejecutaban, UNIX.
			\item<3-> Al no existir un sistema centralizado, era muy difícil administrar los recursos y los costos.
			\item<4-> La elección de un sistema antiguo para ser ejecutado en máquinas personales dificultó las cosas
		\end{itemize}	
	\end{frame}
  
	\begin{frame}
		\frametitle{Introducción}
		\framesubtitle{Motivación}	
		\begin{itemize}
			\item<1-> Plan 9 nació a finales de los años 80, como un intento de tener ambas cosas: construir un sistema que fuera administrado centralizadamente y que fuese barato, usando modernos microordenadores como base.
			\item<2-> Diferentes ordenadores podrían manejar diferentes tareas, pequeñas y baratas máquinas en oficinas que sevirían como terminales proporcionando acceso a recursos centralizados compartidos por diferentes servidores.
			\item<3-> El objetivo inicial era crear un UNIX a base de sistemas pequeños
		\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{Diseño}
		\framesubtitle{Bases}
		\begin{itemize}
			\item<1-> Los problemas con UNIX eran demasiado profundos para arreglarlos, pero algunas de sus ideas podían mantenerse.  administrado centralizadamente y que fuese barato, usando modernos microordenadores como base.
			\item<2-> Se creo un protocolo a nivel de red llamado 9P, para permitir el acceso a sistemas remotos.
			\item<3-> Espacios de nombres por proceso.
			\item<4-> Recursos como parte del sistema de archivos.
		\end{itemize}
	\end{frame}
  
    \begin{frame}
		\frametitle{Diseño}
		\framesubtitle{Principios}
		\begin{itemize}
			\item<1-> Los recursos son nombrados y accedidos como ficheros en un sistema de ficheros jerárquico.
			\item<2-> Hay un protocolo estándar, llamado 9P, para acceder a esos recursos.
			\item<3-> Las distintas jerarquías proporcionadas por servicios diferentes se unen en un solo espacio de nombres jerárquico privado.
		\end{itemize}
	\end{frame}
  
	\begin{frame}
		\frametitle{Diseño}
		\framesubtitle{Estructura}
		\begin{itemize}
			\item<1-> Una instalación Plan 9 grande tiene un número de ordenadores conectados en red.
			\item<2-> Cada uno proporcionando un tipo particular de servicio.
			\item<3-> Las distintas máquinas con pantalla, teclado y ratón proporcionan acceso a los recursos de la red.
			\item<4-> Servidores multiprocesadores comparten ciclos de procesamiento.
			\item<5-> Otros servidores prestan diversos recursos (sistema de archivos, dispositivos, etc).
		\end{itemize}
	\end{frame}
	
	\begin{frame}
		\frametitle{Diseño}
		\framesubtitle{Estructura}
		\includegraphics[width=11cm]{estructura.png}
	\end{frame}

	\begin{frame}
		\frametitle{Diseño}
		\framesubtitle{Todo es un archivo}
		\begin{itemize}
			\item<1-> Todos los servicios disponibles en la red o localmente exportan jerarquías de ficheros.
			\item<2-> Plan 9 ofrece la habilidad de personalizar la visión del sistema que ve un usuario, a esta vista la llamaremos \textbf{Espacio de nombres local}.
			\item<3-> Los recursos importantes para el usuario son puestos juntos en su espacio de nombres personal, y este puede acceder de forma completamente transparante, sin importar su ubicación real en el sistema.
      	\end{itemize}
	\end{frame}
  
	\begin{frame}
		\frametitle{Diseño}
		\framesubtitle{¿Esto no pasa en UNIX?}
		\pause
		\begin{Huge}
   	     ¡NO!
    	\end{Huge}
    	\pause
		\begin{itemize}
			\item<1-> Entre otros, los procesos\footnote{Actualmente esto sí está en la mayoría de los UNIX modernos} y las conexiones de red no figuran en el filesystem
			\item<2-> La configuración de los dispositivos se hace con una llamada al syscall ioctl (ej: velocidad en el puerto serie)
		\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{Espacio de nombres}
		\framesubtitle{Espacio de nombres local}
		\begin{itemize}
			\item<1-> Cada proceso tiene un espacio de nombres local.
			\item<2-> De manera similar a UNIX, se utiliza un sistema jerárquico con forma de árbol para representarlo.
			\item<3-> Los servicios de Plan 9 que exportan jerarquías de ficheros incluyen dispositivos E/S, servicios de backup, el sistema de ventanas, interfaces de red, y muchos otros.
			\item<4-> Los diferentes recursos son agregados al espacio de nombres local.
			\item<5-> Los procesos acceden y usan estos dispositivos de forma transparente.
		\end{itemize}
	\end{frame}
	
	\begin{frame}
		\frametitle{Espacio de nombres}
		\framesubtitle{Ejemplos}
		\begin{itemize}
			\item<1-> /dev/cons			
			\item<2-> /dev/mouse
			\item<3-> /bin/date
			\item<4-> /dev/time
			\item<5-> /proc
			\item<6-> /net/tcp/0
		\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{Espacio de nombres}
		\framesubtitle{System calls}
		\begin{block}{mount}
			Engancha una nueva jerarquía al espacio de nombres existente.
		\end{block}				
		\begin{block}{bind}
			Duplica una parte del espacio de nombres en otro punto del mismo espacio.
		\end{block}				
		\begin{block}{unmount}
			Me permite retirar/desmontar componentes o servicios del espacios de nombres actual.
		\end{block}		
	\end{frame}
	
	\begin{frame}
		\frametitle{Espacio de nombres}
		\framesubtitle{Union Mounts}
			\begin{itemize}
				\item<1-> Plan 9 permite montar varios servicios/directorios en un único punto de montaje.
				\item<2-> La semántica de acceso en este caso depende del orden en el que estos directorios están montados.
				\item<3-> La creación de archivos en un union mount es una opción al agregar un directorio a la unión (está deshabilitada por defecto). La regla de creación es igual al caso anterior (primer directorio que permita la creación o primer directorio donde exista el archivo). En el primer caso, si la creación del archivo falla, la misma es abortada.
			\end{itemize}
	\end{frame}
	
	\input{protocol_9p}
		
	\begin{frame}
		\frametitle{Herramientas de programación}
		\framesubtitle{Lenguajes de programación}
			Las herramientas que componen el sistemas están programadas con los siguientes lenguajes:
			\begin{itemize}
				\item<1-> Scripts de shell (rc).
				\item<2-> C, usando en su gran mayoria ANCI C.
				\item<3-> Alef, un lenguaje parecido a C, pero con soporte mas transparente para programación concurrente.
			\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{Herramientas de programación}
		\framesubtitle{Portabilidad}
			\begin{itemize}
				\item<1-> Plan 9 es portable a través de una variedad de arquitecturas de procesador.
				\item<2-> Dentro de una sola sesión de computación, es normal usar varias arquitecturas, quizá el sistema de ventanas corra en un procesador Intel, conectado a un servidor de CPU basado en MIPS, con ficheros residentes en una SPARC.
				\item<3-> Para que esta heterogeneidad sea transparente, debe haber convenciones respecto al intercambio de datos entre programas.
			\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{Herramientas de programación}
		\framesubtitle{Portabilidad}
			\begin{itemize}
				\item<1-> Para evitar problemas de orden de byte, los datos se comunican entre programas como texto, siempre que resulte práctico. 
				\item<2-> Si la cantidad de datos es suficientemente alta como para que se necesite un formato binario; estos datos se comunican como un flujo de bytes con una codificación predefinida para valores multi-byte.
				\item<3-> En el caso raro en que un formato sea tan complejo como para ser definido como una estructura, la estructura nunca se comunica como una unidad, sino que se descompone en campos individuales, se codifica en un flujo de bytes ordenados y se reensambla en el receptor.
				\item<4-> Estas convenciones afectan a todos los datos, desde el núcleo o información de estado de programas de aplicación hasta ficheros objeto intermedios generados por el compilador.
			\end{itemize}
	\end{frame}
	
	\begin{frame}
		\frametitle{Herramientas de programación}
		\framesubtitle{Portabilidad}
			\begin{block}{}
				Los programas, incluido el núcleo, a menudo presentan sus datos a través de un interfaz de sistema de ficheros, un mecanismo de acceso que es inherentemente portable.
			\end{block}
				Ejemplos:
			\pause
			\begin{itemize}
				\item<1-> El reloj del sistema es representado mediante un número decimal en el fichero /dev/time; la función de librería time (no hay una llamada del sistema time) lee el fichero y lo convierte en binario.
				\item<2-> El estado de un proceso es representado por una cadena de texto en el fichero llamado status en el sistema de ficheros /proc asociado a cada proceso. Por lo tanto comando ps en Plan 9 es trivial: muestra los contenidos de los ficheros de estado deseados después de un ligero formateo.
			\end{itemize}
	\end{frame}
	
	\begin{frame}
		\frametitle{Herramientas de programación}
		\framesubtitle{Compilación}
			\begin{itemize}
				\item<1-> Cada arquitectura soportada tiene su propio compilador y linker.
				\item<2-> Los compiladores de C y Alef producen ficheros intermedios que están codificados de manera portable; los contenidos son únicos para la arquitectura destino, pero el formato de los ficheros es independiente del tipo de procesador que compile.
				\item<3-> Cuando un compilador para una arquitectura dada es compilado en otro tipo de procesador y luego usado para compilar un programa allí, el código intermedio producido será idéntico al producido en el procesador nativo.
				\item<4-> Aunque el linker de cada arquitectura acepta solamente ficheros intermedios producidos por compiladores para esa arquitectura, esos ficheros pueden haber sido generados por un compilador ejecutado en otro tipo de procesador.
			\end{itemize}
	\end{frame}
	
	\begin{frame}
		\frametitle{Herramientas de programación}
		\framesubtitle{Programación concurrente}
			El soporte para programación paralela de Plan 9 tiene dos aspectos:
			\begin{itemize}
				\item<1-> El núcleo proporciona un modelo simple de proceso y unas cuantas llamadas al sistema cuidadosamente diseñadas para la sincronización y la compartición.
				\item<2-> Un nuevo lenguaje de programación paralela, llamado Alef que soporta la programación concurrente
			\end{itemize}
	\end{frame}
	
	\begin{frame}
		\frametitle{Herramientas de programación}
		\framesubtitle{Programación concurrente}
		La mayoria de los sistemas operativos a implementan dos clases de procesos: 
			\begin{itemize}
				\item<1-> Los procesos normales estilo UNIX.
				\item<2-> Los hilos ligeros (threads).
			\end{itemize}
		\begin{block}{}
		Plan 9 proporciona una sola clase de procesos pero permite un control preciso de la compartición de recursos entre procesos, como memoria o descriptores de ficheros. 
		\end{block}			
	\end{frame}
	
	\begin{frame}
		\frametitle{Herramientas de programación}
		\framesubtitle{Programación concurrente}
			\begin{itemize}
				\item<1-> Los procesos se crean usando la llamada del sistema \textbf{rfork}.
				\item<2-> Esta función toma un solo argumento, un vector de bits que especifica cuál de los recursos del proceso padre deben ser compartidos, copiados o creados de nuevo en el proceso hijo.
				\item<3-> Los recursos controlados por \textbf{rfork} incluyen el espacio de nombres, el entorno, la tabla de descriptores de ficheros, segmentos de memoria, y \textit{notes} (equivalentes a señales en UNIX).
			\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{ Sistema gráfico de Ventanas}
		\framesubtitle{Introducción}
			\begin{itemize}
				\item<1-> Plan 9 está pensado para ser usado desde una máquina con una pantalla corriendo un sistema de ventanas.
				\item<2-> El sistema de ventanas utilizado en las primeras versiones fue 8 1/2.
				\item<3-> Actualmente Plan 9 utiliza una version mejorada de 8 1/2, llamada RIO.
				\item<4-> Proporciona servicios de I/O en formato texto y gráficos en mapas de bits para programas cliente, locales y remotos, con el objeto de ofrecer un servicio multiplexado de archivo para tales clientes.
			\end{itemize}
	\end{frame}	
	
	\begin{frame}
		\frametitle{ Sistema gráfico de Ventanas}
		\framesubtitle{Características}
			\begin{itemize}
				\item<1-> 8 1/2 conecta la única pantalla, ratón, y teclado del terminal dentro de un array de terminales virtuales independientes.
				\item<2-> Cada ventana se crea en un espacio de nombres separado. 
				\item<3-> Estas podrían ser terminales de texto con soporte de shell y la usual suite de herramientas o aplicaciones gráficas que requiriesen de todos los recursos de la pantalla de mapa de bits.
				\item<4-> El texto es representado en UTF, una codificación de la Unicode Standard. 
				\item<5-> 8 1/2 sirve un grupo de archivos en el directorio convencional /dev con nombres como cons, mouse, y screen. 
				\item<5-> Los clientes de 8 1/2 se comunican con el sistema de ventana leyendo y escribiendo esos archivos.
			\end{itemize}
	\end{frame}	

	\begin{frame}
		\frametitle{Sistemas de archivos}
		\framesubtitle{Introducción}
		\begin{block}{}
			En Plan 9, los sistemas de archivos se pueden implementar dentro del kernel o como servicios de usuario (la opción más utilizada).
		\end{block}
		\begin{itemize}
			\item<2-> Los dos sistemas de archivos más importantes de Plan 9 son:
			\begin{itemize}
				\item<3-> Fossil. Este es el sistema de archivos que usa Plan 9 para la raíz del sistema. La propiedad más importante del mismo es el soporte de snapshots (Permite ver el sistema de archivos como estaba al momento de crear el mismo).
				\item<4-> Venti. Este es un sistema de archivos WORM (Write Once Read Many). Está pensado para almacenar en forma permanente snapshots de fossil.
			\end{itemize}
		\end{itemize}
		\begin{block}{}<5->
			En las diapositivas siguientes, describimos el sistema de almacenamiento que utilizaban los autores del paper.
		\end{block}
	\end{frame}
	
	\begin{frame}
		\frametitle{Sistema de almacenamiento}
		\framesubtitle{Servidor de archivos}
			\begin{itemize}
				\item<1-> Un servidor de ficheros central almacena los ficheros permanentes y los presenta a la red como una jerarquía exportada usando 9P.
				\item<2-> El servidor es un sistema independiente, accesible solo a través de la red, diseñado para hacer un bien una sola cosa.
				\item<3-> No ejecuta procesos de usuario, solo un conjunto fijo de rutinas compiladas en la imagen de arranque. 
				\item<4-> La jerarquía principal exportada por el servidor es un solo árbol, que representa ficheros en varios discos.
				\item<5-> Otros árboles de ficheros exportados por el servidor incluyen sistemas de propósito especial, como almacenamiento temporal, y servicios de backup.
			\end{itemize}
	\end{frame}
	
	\begin{frame}
		\frametitle{Sistema de almacenamiento}
		\framesubtitle{Servidor de archivos}
		El servidor de ficheros tiene tres niveles de almacenamiento:
		\begin{itemize}
			\item<1-> 100 megabytes de buffers de memoria.
			\item<2-> 27 gigabytes de discos.
			\item<3-> 350 gigabytes de almacenamiento en masa, en un jukebox WORM (write-once-read-many).
		\end{itemize}
		El disco es un caché para el WORM y la memoria es un caché para el disco; cada uno es más rápido, y ve un orden de magnitud más de tráfico que el nivel que cachea. 
	\end{frame}
	
	\begin{frame}
		\frametitle{Sistema de almacenamiento}
		\framesubtitle{Dispositivo de almacenamiento WORM}
		\begin{itemize}
			\item<1-> Realiza el almacenamiento definitivo.
			\item<2-> Una vez el día el sistema realiza un dump del sistema de archivos automáticamente.
			\item<3-> El sistema es congelado y todos los bloques modificados desde el último volcado son puestos a la cola para ser escritos en el WORM.
			\item<4-> Una vez que los bloques están en la cola, el servicio se restablece, y la raíz del sistema de ficheros volcado aparece en una jerarquía de todos los volcados que se han realizado hasta el momento, nombrados por su fecha.
		\end{itemize}
	\end{frame}
	
	\begin{frame}
		\frametitle{Sistema de almacenamiento}
		\framesubtitle{Usos del sistema de backup}
		Hay dos maneras de usar el sistema de ficheros de volcado:
		\begin{itemize}
			\item<1-> Los usuarios pueden hojear el sistema de ficheros volcado directamente, o enganchar piezas del mismo en su espacio de nombres. Por ejemplo, para tracear un error, lo más directo es compilar lo que se tenía hace tres meses, o linkear un programa con la librería de ayer. 
			\item<2-> El otro (muy raro) uso es hacer una copia de seguridad del sistema. En caso de desastre, el sistema de ficheros activo puede ser inicializado desde un volcado, borrando el caché del disco y poniendo la raíz del sistema activo como una copia de la raíz volcada.
		\end{itemize}
		 No hay un sistema de backup como tal; en su lugar, puesto que los volcados están en el espacio de nombres, los problemas de backup pueden resolverse con herramientas estándar como cp, ls, grep, y diff.
	\end{frame}
	
	\begin{frame}
		\frametitle{Sistema de almacenamiento}
		\framesubtitle{Caché de ficheros}
		\begin{itemize}
			\item<1-> El protocolo 9P no tiene soporte explícito para cachear ficheros en un cliente. 
			\item<2-> La extensa memoria del servidor central de ficheros actúa como un caché compartido para todos sus clientes, lo que reduce la cantidad total de memoria necesaria para todas las máquinas de la red.
			\item<3-> No obstante, hay razones de peso para cachear ficheros en el cliente, como una conexión lenta con el servidor.
			\item<4-> Cada cliente corre un servidor que se encarga de mantener un cache local coherente con el servidor central.
			\item<5-> Este servidor de nivel usuario se interpone en la conexión 9P al servidor remoto y monitorea el tráfico, copiando datos al disco local. Cuando ve una lectura de datos conocidos, contesta directamente, mientras que las escrituras las pasa inmediatamente para mantener los datos centrales actualizados.
		\end{itemize}
	\end{frame}
	
\input{networking}
	
	\begin{frame}
		\frametitle{Seguridad}
		\framesubtitle{Introducción}
		\begin{itemize}
			\item<1-> El paper NO habla de la seguridad general del sistema.
			\item<2-> Sólo se habla de los mecanismos de autenticación y autorización.
		\end{itemize}
	\end{frame}
	\begin{frame}
		\frametitle{Seguridad}
		\framesubtitle{Autenticación}
		\begin{itemize}
			\item<1-> El mecanismo de autorización es único para todos los servicios (es parte del protocolo 9P).
			\item<2-> Se basa en challenge-response.
			\item<3-> Cada usuario tiene asignada una clave DES para este mecanismo (no se envían en texto plano ni los algoritmos ni las claves).
			\item<4-> En el caso de usuarios ``de sistema'', esta clave se almacena en ROM, en el caso de usuarios ``comunes'', esta clave se deriva a partir de su password.
			\item<5-> En Plan 9, hay 3 actores durante la autenticación.
			\begin{itemize}
				\item<6-> El cliente que está tratando de acceder al recurso.
				\item<7-> El servicio que posee el recurso (El servicio a su vez representa a un usuario).
				\item<8-> El servidor de autenticación, que genera los tickets de sesión (y tiene almacenadas las claves de todos los usuarios).
			\end{itemize}
		\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{Seguridad}
		\framesubtitle{Autenticación}
		\begin{itemize}
			\item<1-> La autenticación es de dos vías (El servicio verifica la identidad del cliente y el cliente verifica la identidad del servicio). La autenticaicón es siempre entre usuarios.
			\item<2-> Una vez que ambos verificaron la identidad del otro, el cliente se conecta al servidor de autenticación para obtener los tickets de sesión (encriptados con las claves del cliente y servidor respectivamente), y le entrega al servidor el ticket correspondiente.
			\item<3-> El mecanismo es similar a Kerberos, pero las máquinas no necesitan tener sus relojes sincronizados. Además, soporta una relación ``en nonbre de'', que permite que un usuario se pueda autenticar con las credenciales de otro usuario.
		\end{itemize}
	\end{frame}
	% La sección "Authenticating external connections" no la entendí...
	\begin{frame}
		\frametitle{Seguridad}
		\framesubtitle{Usuarios especiales}
		\begin{itemize}
			\item<1-> Plan 9 no tiene noción de superusuario (root). Ningún usuario puede saltear los permisos de un archivo del cual no es dueño
			\item<2-> El manejo de permisos administrativos queda a cargo de cada servidor.
			\begin{itemize}
				\item<3-> Como ejemplo, los autores mencionan que, en el servidor de archivos de su organización, tienen un usuario que se encarga de las tareas de administración que sólo se puede loguear desde la consola física.
				\item<4-> Además, mencionan que el servidor del CPU tiene un usuario que permite matar procesos de otros usuarios
			\end{itemize}
			\item<5-> Sí existe un usuario restringido ``none'', que sólo está autorizado a leer archivos que permiten ser leídos por todos los usuarios.
			\begin{itemize}
				\item<6-> Este usuario se puede usar para brindar acceso anónimo FTP a la máquina (sacando del namespace el directorio /bin para aumentar la seguridad).
				\item<7-> También se utiliza durante la autenticación con los servidores que proveen capacidad de cálculo.
			\end{itemize}
		\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{Seguridad}
		\framesubtitle{Autenticación con proxy - El comando cpu}
		\begin{itemize}
			\item<1-> El comando cpu tiene dos fases de autenticación
			\item<2-> En la primera fase, el cliente se autentica con el servidor de cálculo.
			\begin{itemize}
				\item<2-> Cuando el servidor recibe un pedido, crea un nuevo proceso para atenderlo (usando las credenciales del usuario ``none'' por un tema de seguridad.
			\end{itemize}
			\item<3-> Finalizada la primera fase, el servidor de CPU crea el namespace utilizando las credenciales del usuario que inició el pedido para autenticarse con los servidores correspondientes (utilizando el usuario encargado de la administración del servidor y el mecanismo ``speak for'').
			\item<4-> Para que estas autenticaciones tengan éxito, el usuario que el servidor usa para realizar estas autenticaciones debe figurar en la base de datos que indica qué usuarios pueden autenticarse en nombre del usuario que se conectó al servidor de CPU.
		\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{Seguridad}
		\framesubtitle{Autorización}
		\begin{itemize}
			\item<1-> La autorización para acceder a todos los recursos se basa en los permisos de archivos de UNIX.
			\item<2-> Como en UNIX, el sistema tiene usuarios comunes y grupos, pero a diferencia de UNIX, existe el concepto de líder de un grupo
			\begin{itemize}
				\item<2-> El líder puede agregar miembros al grupo y cambiar los permisos del grupo sobre archivos
				\item<2-> Si no se especifica un líder de grupo, todos los miembros tienen los permisos de líder
			\end{itemize}
			\item<3-> Los archivos se crean con el UID del usuario que creó el archivo, y el GID del directorio donde se creó (los dispositivos se manejan en forma especial).
		\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{Seguridad}
		\framesubtitle{Autorización - Ejemplos}
		\begin{itemize}
			\item<1-> El paper menciona dos ejemplos del mecanismo de autorización
			\begin{itemize}
				\item<2-> Para permitir que un usario inspeccione/debugee un proceso que está corriendo otro usuario, el usuario que está corriendo el proceso simplemente cambia los permisos de los archivos en el subdirectorio de /proc correspondiente
				\item<2-> Los dumps del filesystem son accesibles en todo momento con los permisos que tenían los archivos en el momento en que el mismo fue creado.
			\end{itemize}
		\end{itemize}
	\end{frame}

	\begin{frame}
		\frametitle{Performance}
		\begin{itemize}
			\item<1-> Para medir la performance de un sistema operativo, los investigadores diseñaron programa muy sencillo que mide los tiempos de hacer:
			\begin{itemize}
				\item<2-> Cambio de contexto
				\item<3-> Llamada a sistema ``simple''
				\item<4-> Creación de proceso/thread nuevo
				\item<5-> Latencia al escribir en un pipe
				\item<6-> Ancho de banda del pipe
			\end{itemize}
			\item<7-> Este programa fue implementado en Plan 9 y en IRIX 5.6, y ejecutado sobre el mismo hardware.
		\end{itemize}
	\end{frame}
	
	\begin{frame}
		\frametitle{Performance}
		Resultado:
		\begin{center}
			\includegraphics[width=7cm]{performance.png}		
		\end{center}
		\begin{itemize}
			\item<8-> El resultado de esto es que, salvo en el ancho de banda de los pipes, Plan 9 es más rápido que IRIX.
			\item<9-> Los autores concluyen que la performance de Plan 9 es competitiva con respecto a sistemas operativos comerciales.
		\end{itemize}
	\end{frame}
	
	\begin{frame}
		\frametitle{Impacto}
			\begin{itemize}
				\item<1-> Plan 9 demostró que el concepto central de Unix (que cualquier interfaz de sistema podía representarse como conjuntos de archivos) podía implementarse y hacerse funcional en un moderno sistema distribuido.
				\item<2-> Algunas ideas de Plan 9 han sido implementadas en otros sistemas operativos, .
				\item<3-> Sistemas Unix como Linux han implementado partes del sistema de archivos de Plan 9 (por ejemplo el directorio /proc), la codificación UTF-8 y formas limitadas parecidas a la llamada al sistema rfork. 
				\item<4->  Varias de las aplicaciones y herramientas de Plan 9 han sido portadas a Unix y Linux y han alcanzado algún nivel de popularidad (rc shell).
			\end{itemize}
	\end{frame}
	
	\begin{frame}
		\begin{Huge}
			\begin{center}
				\includegraphics[width=5cm]{glenda.jpg} \\
				Fin.
			\end{center}
		\end{Huge}
	\end{frame}
				
\end{document}
